1. Field of the Invention
The present invention generally relates to peer-to-peer streaming video services, and more particularly to mechanisms for providing rebroadcast services to a streaming video installation.
2. Background Description
As Internet use has become more prevalent, there has been an increased interest by average users to offer streaming data broadcasting services of their own. One such example is the ability to transmit live video from home computers for the purpose of remote monitoring. This undertaking is still prohibitive for the average user. The cost and difficulty of acquiring and installing the software necessary to offer generalized services over the Internet is usually prohibitive. Proper access control and security are also a problem. Those that are successful at setting up basic Internet services often do not understand the procedure necessary to configure and maintain access control lists to keep their systems safe from outside tampering and interception. One of the most significant barriers is that the average Internet user does not receive a static Internet address from his or her Internet Service Provider (ISP). This means that each time he or she connects to the Internet, the hosting system receives a different Internet address effectively preventing others from accessing the system in a consistent manner. This is similar to receiving a different phone number every day. There is no easy way for a viewer to know where to contact a server. If average Internet users wish to offer their own Internet services, it is desirable to have these highly technical issues handled transparently without complex procedures.
Prior art approaches to live streaming video or other data services fall into two categories: the Two-Node Architecture or the Linear Three-Node Architecture. The first and most common approach is the Two-Node Architecture. With this architecture, the user/source of data services (the Sender) sets up a server on the Internet, which is then available to one or more Viewers. An advantage of this approach is that the data stream is connected directly between the Viewer's and the Sender's server. This allows a strong level of privacy and security and at the same time allows the Viewer to control its individual data stream. However, a drawback of this approach is that it requires the Sender to acquire, install, configure and maintain his or her own Web server system and utilize a static IP address. When a requester or Viewer wishes to receive data on a remote computer, he or she must know how to locate the machine with the data (the Sender's server) and then have access to the functions required to send that data to the Viewer.
The ability to locate the Sender's server is difficult with most Internet services because of the prevalence of dynamic Internet addressing. With dynamic Internet addressing, the Viewer will not have a consistent address to use in order to retrieve data from the server. Finally, when the Viewer locates the Sender's server machine, he or she must have proper access permissions. If the person owning the server (the Sender) does have a static Internet address, he or she must still install, configure and maintain his or her own complex World Wide Web site and must enforce security policies to prevent unauthorized access and tampering (“hacking”). These tasks are difficult and cumbersome for the average Internet user.
Since this approach is not a database-centric approach, there are also further difficulties in providing features such as status, logging, and session handling. The Two-Node Architecture is more difficult to configure than other architectures, and for the average Internet user this often results in limited system security and breaches of system integrity. Another drawback of this approach is that all of the components including the server and the Web site must reside on the same physical machine, thereby reducing scalability. Further, this system is prohibitively costly and complex for the average user. These problems are typical of a two-node client/server architecture where you have a direct connection between the Viewer and the Sender's server.
Other systems attempt to overcome the problems of the Two-Node Architecture by adding a third node. These systems use a Linear Three-Node Architecture. Both the Viewer and Sender's server connect to a third node, called the Mediator Node, which has a static Internet address. This connection model solves the location problem because the Viewer does not need to know where the server of interest is located. It simply connects to the Mediator Node. This approach also overcomes the access problem. The Mediator Node handles the authentication of the Viewer and ensures that he or she has the permissions necessary to connect to the Sender's server. This approach does not require the Sender to maintain a Web site; it can use a database-centric approach, and can offer greater scalability. Furthermore, the Sender has the potential to establish access control lists using the centralized Web site of the Mediator Node.
However, this approach has a serious drawback: the Mediator Node must handle the actual data stream from the server to the viewer. This process creates several problems. First, the Mediator Node must be able to handle the increased resource requirements, and so this approach does not scale well when many Viewers are using the system. Secondly, there is a reduction in privacy and control, since all of the Sender's streaming data are now accessible to the Mediator Node. Once the Viewer's and Sender's server are connected through the Mediator Node, all of the data requested by the Viewer must travel through the Mediator Node before reaching the Viewer.
A further approach (taken by InetCam) is to use a third Mediator node just to handle location information. This approach uses a dynamic DNS service to allow clients to locate the video source. However, this requires that the user handle the security and access controls on the Sender side. This includes setting up and configuring a bundled web server including creating user access accounts and creating a web site. This approach makes the system difficult for the end user.
An additional approach (taken by iFriends) uses a Mediator node but does not allow the user to stop and start a stream using the viewer applet directly. Accessing or leaving a web page controls the stream. The web server handles the session tracking. This reduces the user's control over a stream requiring them to leave or close a web page to stop the stream. As a result, this system is not suitable for remote monitoring. This approach does not allow a user to simply leave their viewer software open without actually accessing the stream. This negatively impacts network bandwidth.
The foregoing deficiencies in the prior art were substantially overcome by U.S. Pat. No. 7,103,770 “POINT TO POINT DATA STREAMING USING A MEDIATOR NODE FOR ADMINISTRATION AND SECURITY” to Bartley C. Conrath (the '770 patent), assigned in common with the present invention. The '770 patent provides optionally for a server based Media Relay. However, a server based MediaRelay does not provide a distributed and personal user control over the rebroadcast of streaming data to a wider number of viewers.